Describe your changes:

Fixes #32792

CreateTableRequest had no certification field, so database metadata ingestion had to create/update a table first and follow up with a separate JSON Patch to /certification. That patch is invisible to sourceHash, so a source-system change that is only a certification update produces the same hash as the previous run and the bulk fast-path silently skips it.

This adds an optional certification (AssetCertification) field to CreateTableRequest, threads it through TableMapper, and narrows the bot-overwrite guard in EntityRepository.updateCertification so a bot's explicit certification value is applied instead of always being reverted.

Type of change:

• Improvement

High-level design:

EntityRepository.updateCertification() had a guard that reverted any bot PUT once a certification existed, regardless of what the request contained — a workaround for CreateTableRequest never carrying a certification value, so every bot PUT implicitly meant "no certification" and would otherwise have wiped it on every re-sync.

Now that a bot can supply an explicit value, the guard only needs to protect against omission:

if (operation.isPut()
    && !nullOrEmpty(original.getCertification())
    && updatedByBot()
    && !overrideMetadata
    && updatedCertification == null) {
  updated.setCertification(original.getCertification());
  return;
}

This mirrors the overrideMetadata escape hatch already used for description/owners/domains on the same class, rather than introducing a new mechanism:

• Certification omitted from the request -> preserved (most connectors still won't populate it).
• Certification explicitly supplied (same or different value) -> proceeds to the existing validate/apply/recordChange path.
• overrideMetadata=true -> bypasses the guard entirely, consistent with the other protected fields.

No change was needed to generate_source_hash(): it hashes the full request via model_dump(), so certification is automatically included in the hash once it's a model field.

Alternatives considered:

• Excluding certification from sourceHash as a special case — rejected, since a certification-only source change would still look "unchanged" to the bulk fast path.
• Keeping the create-then-patch workaround but making the patch more reliable — rejected, doesn't fix the sourceHash blind spot.

Tests:

Use cases covered

• Ingestion sends CreateTableRequest.certification on table create -> certification is applied.
• Ingestion omits certification on a later run -> existing certification (e.g. set through the UI) is preserved, not wiped.
• Ingestion sends a changed certification value on a later run -> the new value is applied and sourceHash differs, so the bulk fast-path doesn't skip it.
• overrideMetadata=true still clears certification when the request omits it, matching existing behaviour for other protected fields.

Unit tests

• I added unit tests for the new/changed logic.
• Files added/updated:
  • openmetadata-service/src/test/java/org/openmetadata/service/jdbi3/EntityRepositoryCertificationTest.java — 4 new tests exercising updateCertification()'s guard directly (bot-omit-preserves, bot-explicit-applies, bot-omit-with-overrideMetadata-clears, human-omit-clears).
  • ingestion/tests/unit/utils/test_source_hash.py — certification-added/changed/omitted/equivalent-payload hash stability tests for generate_source_hash.

Backend integration tests

• Not applicable (no new API endpoint; existing PUT /tables already accepts CreateTableRequest).

Ingestion integration tests

• Not applicable (schema/model change only; connectors adopting this field are a separate follow-up).

Manual testing performed

1. Ran the full EntityRepositoryCertificationTest suite (32/32 passing) and the full org.openmetadata.service.jdbi3.** package (616/616 passing).
2. Ran ingestion/tests/unit/utils/test_source_hash.py and ingestion/tests/unit/topology/test_runner.py (all passing) after regenerating Python models from the updated schema.
3. Verified mvn spotless:apply and mvn spotless:check clean on openmetadata-service.

UI screen recording / screenshots:

Not applicable.

Checklist:

• I have read the CONTRIBUTING document.
• My PR title is Fixes <issue-number>: <short explanation>
• My PR is linked to a GitHub issue via Fixes #<issue-number> above.
• I have commented on my code, particularly in hard-to-understand areas.
• For JSON Schema changes: I updated the migration scripts or explained why it is not needed — certification is a new optional field on CreateTableRequest, so no migration is needed (existing stored data is unaffected).
• I have added tests (unit / integration / Playwright as applicable) and listed them above.

• I have added tests around the new logic.